Reacts hemliga ingrediens: En djupdykning i Reconciliation-algoritmen och Virtual DOM-diffing

` representeras så här:

{ type: 'div', props: { className: 'container', children: 'Hello World' } }

Eftersom dessa bara är JavaScript-objekt är det otroligt snabbt att skapa och manipulera dem. Det innebär ingen interaktion med webbläsar-API:er, så det blir inga reflows eller repaints.

Hur fungerar den virtuella DOM:en?

VDOM möjliggör en deklarativ strategi för UI-utveckling. Istället för att tala om för webbläsaren hur den ska ändra DOM steg-för-steg (imperativt), deklarerar du helt enkelt hur gränssnittet ska se ut för ett givet state (deklarativt). React sköter resten.

Processen ser ut så här:

1. Initial rendering: När din applikation först laddas skapar React ett komplett virtuellt DOM-träd för ditt gränssnitt och använder det för att generera den initiala verkliga DOM:en.
2. State-uppdatering: När applikationens state ändras (t.ex. när en användare klickar på en knapp), skapar React ett nytt virtuellt DOM-träd som återspeglar det nya state.
3. Diffing: React har nu två virtuella DOM-träd i minnet: det gamla (före state-ändringen) och det nya. Därefter körs dess "diffing"-algoritm för att jämföra dessa två träd och identifiera de exakta skillnaderna.
4. Batching och uppdatering: React beräknar den mest effektiva och minimala uppsättningen operationer som krävs för att uppdatera den verkliga DOM:en så att den matchar den nya virtuella DOM:en. Dessa operationer samlas ihop (batchas) och tillämpas på den verkliga DOM:en i en enda, optimerad sekvens.

Genom att batcha uppdateringar minimerar React direkt interaktion med den långsamma DOM:en, vilket avsevärt förbättrar prestandan. Kärnan i denna effektivitet ligger i "diffing"-steget, vilket formellt kallas för Reconciliation-algoritmen.

Hjärtat i React: Reconciliation-algoritmen

Reconciliation är processen genom vilken React uppdaterar DOM för att matcha det senaste komponentträdet. Algoritmen som utför denna jämförelse är vad vi kallar "diffing-algoritmen".

Teoretiskt sett är det ett mycket komplext problem att hitta det minimala antalet transformationer för att omvandla ett träd till ett annat, med en algoritmkomplexitet i storleksordningen O(n³), där n är antalet noder i trädet. Detta skulle vara för långsamt för verkliga applikationer. För att lösa detta gjorde Reacts team några briljanta observationer om hur webbapplikationer vanligtvis beter sig och implementerade en heuristisk algoritm som är mycket snabbare — den arbetar i O(n)-tid.

Heuristiken: Att göra diffing snabb och förutsägbar

Reacts diffing-algoritm bygger på två primära antaganden eller heuristiker:

Heuristik 1: Olika elementtyper producerar olika träd

Detta är den första och mest direkta regeln. När React jämför två VDOM-noder tittar den först på deras typ. Om typen av rotelementen är olika, antar React att utvecklaren inte vill försöka omvandla det ena till det andra. Istället tar den en mer drastisk men förutsägbar strategi:

• Den river ner hela det gamla trädet, avmonterar alla gamla komponenter och förstör deras state.
• Den bygger ett helt nytt träd från grunden baserat på den nya elementtypen.

Tänk till exempel på denna ändring:

Före: <div><Counter /></div>
Efter: <span><Counter /></span>

Även om barnkomponenten `Counter` är densamma, ser React att roten har ändrats från en `div` till en `span`. Den kommer att helt avmontera den gamla `div`:en och `Counter`-instansen inuti den (och förlora dess state) och sedan montera en ny `span` och en helt ny instans av `Counter`.

Viktigt att komma ihåg: Undvik att ändra rotelementets typ i ett komponent-underträd om du vill bevara dess state eller undvika en fullständig omrendering av det underträdet.

Heuristik 2: Utvecklare kan antyda stabila element med `key`-propen

Detta är förmodligen den mest kritiska heuristiken för utvecklare att förstå och tillämpa korrekt. När React jämför en lista med barnelement är dess standardbeteende att iterera över båda listorna av barn samtidigt och generera en mutation där det finns en skillnad.

Problemet med indexbaserad diffing

Låt oss föreställa oss att vi har en lista med objekt och vi lägger till ett nytt objekt i början av listan utan att använda nycklar (keys).

Initial lista:

• Objekt B
• Objekt C

Uppdaterad lista (lägg till 'Objekt A' i början):

• Objekt A
• Objekt B
• Objekt C

Utan nycklar utför React en enkel, indexbaserad jämförelse:

1. Den jämför det gamla objektet på index 0 ('Objekt B') med det nya objektet på index 0 ('Objekt A'). De är olika, så den muterar det första objektet.
2. Den jämför det gamla objektet på index 1 ('Objekt C') med det nya objektet på index 1 ('Objekt B'). De är olika, så den muterar det andra objektet.
3. Den ser att det finns ett nytt objekt på index 2 ('Objekt C') och infogar det.

Detta är högst ineffektivt. React har utfört två onödiga mutationer och en insättning, när allt som behövdes var en enda insättning i början. Om dessa listobjekt vore komplexa komponenter med sitt eget state, skulle detta kunna leda till allvarliga prestandaproblem och buggar, eftersom state skulle kunna blandas ihop mellan komponenter.

Kraften i `key`-propen

`key`-propen erbjuder en lösning. Det är ett speciellt strängattribut som du behöver inkludera när du skapar listor av element. Nycklar ger React en stabil identitet för varje element.

Låt oss återbesöka samma exempel, men denna gång med stabila, unika nycklar:

Initial lista:

• Objekt B
• Objekt C

Uppdaterad lista:

• Objekt A
• Objekt B
• Objekt C

Nu är Reacts diffing-process mycket smartare:

1. React tittar på barnen i den nya listan och hittar element med nycklarna 'b' och 'c'.
2. Den vet att elementen med nycklarna 'b' och 'c' redan finns i den gamla listan, så den flyttar dem helt enkelt.
3. Den ser att det finns ett nytt element med nyckeln 'a' som inte fanns tidigare, så den skapar och infogar det.

Detta är mycket effektivare. React identifierar korrekt att den bara behöver utföra en insättning. Komponenterna associerade med nycklarna 'b' och 'c' bevaras och behåller sitt interna state.

Kritisk regel för nycklar: Nycklar måste vara stabila, förutsägbara och unika bland sina syskon. Att använda array-index som nyckel (`items.map((item, index) =>

...

)`) är ett anti-mönster om listan någonsin kan omordnas, filtreras eller få objekt tillagda/borttagna från mitten, eftersom det leder till samma problem som att inte ha någon nyckel alls. De bästa nycklarna är unika identifierare från din data, som ett databas-ID.

Evolutionen: Från Stack till Fiber-arkitektur

Reconciliation-algoritmen som beskrivits ovan var grunden för React under många år. Den hade dock en stor begränsning: den var synkron och blockerande. Denna ursprungliga implementering kallas nu för Stack Reconciler.

Det gamla sättet: The Stack Reconciler

I Stack Reconciler, när en state-uppdatering utlöste en omrendering, skulle React rekursivt gå igenom hela komponentträdet, beräkna ändringarna och tillämpa dem på DOM — allt i en enda, oavbruten sekvens. För små uppdateringar var detta okej. Men för stora komponentträd kunde denna process ta en betydande tid (t.ex. mer än 16 ms), vilket blockerade webbläsarens huvudtråd. Detta skulle få gränssnittet att sluta svara, vilket ledde till tappade bildrutor, hackiga animationer och en dålig användarupplevelse.

Introduktion av React Fiber (React 16+)

För att lösa detta problem genomförde React-teamet ett flerårigt projekt för att helt skriva om den centrala reconciliation-algoritmen. Resultatet, som släpptes i React 16, kallas React Fiber.

Fiber-arkitekturen designades från grunden för att möjliggöra samtidighet (concurrency) — förmågan för React att arbeta på flera uppgifter samtidigt och växla mellan dem baserat på prioritet.

En "fiber" är ett vanligt JavaScript-objekt som representerar en arbetsenhet. Den innehåller information om en komponent, dess indata (props) och dess utdata (children). Istället för en rekursiv genomgång som inte kunde avbrytas, bearbetar React nu en länkad lista av fiber-noder, en i taget.

Denna nya arkitektur möjliggjorde flera viktiga funktioner:

• Inkrementell rendering: Den kan dela upp renderingsarbetet i små bitar och sprida ut det över flera bildrutor.
• Prioritering: Den kan tilldela olika prioritetsnivåer till olika typer av uppdateringar. Till exempel har en användare som skriver i ett inmatningsfält högre prioritet än data som hämtas i bakgrunden.
• Möjlighet att pausa och avbryta: Den kan pausa arbetet med en lågprioriterad uppdatering för att hantera en högprioriterad, och kan till och med avbryta eller återanvända arbete som inte längre behövs.

De två faserna i Fiber

Under Fiber är renderingsprocessen uppdelad i two distinkta faser:

1. Render/Reconciliation-fasen (Asynkron): I denna fas bearbetar React fiber-noder för att bygga ett "work-in-progress"-träd. Den anropar komponenters `render`-metoder och kör diffing-algoritmen för att avgöra vilka ändringar som behöver göras i DOM. Avgörande är att denna fas är avbrytbar. React kan pausa detta arbete för att hantera något viktigare och återuppta det senare. Eftersom den kan avbrytas tillämpar React inga faktiska DOM-ändringar under denna fas för att undvika ett inkonsekvent UI-state.
2. Commit-fasen (Synkron): När "work-in-progress"-trädet är komplett går React in i commit-fasen. Den tar de beräknade ändringarna och tillämpar dem på den verkliga DOM:en. Denna fas är synkron och kan inte avbrytas. Detta säkerställer att användaren alltid ser ett konsekvent gränssnitt. Livscykelmetoder som `componentDidMount` och `componentDidUpdate`, samt `useLayoutEffect`- och `useEffect`-hooks, exekveras under denna fas.

Fiber-arkitekturen är grunden för många av Reacts moderna funktioner, inklusive `Suspense`, concurrent rendering, `useTransition` och `useDeferredValue`, vilka alla hjälper utvecklare att bygga mer responsiva och flytande användargränssnitt.

Praktiska optimeringsstrategier för utvecklare

Att förstå Reacts reconciliation-process ger dig kraften att skriva mer prestanda-effektiv kod. Här är några konkreta strategier:

1. Använd alltid stabila och unika nycklar för listor

Detta kan inte betonas nog. Det är den enskilt viktigaste optimeringen för listor. Använd ett unikt ID från din data (t.ex. `product.id`). Undvik att använda array-index om inte listan är helt statisk och aldrig kommer att ändras.

2. Undvik onödiga omrenderingar

En komponent renderas om ifall dess state ändras eller dess förälder renderas om. Ibland renderas en komponent om även när dess utdata skulle vara identisk. Du kan förhindra detta genom att använda:

• `React.memo()`: En högre ordningens komponent för funktionskomponenter. Den utför en ytlig jämförelse av komponentens props. Om propsen inte har ändrats kommer React att hoppa över omrenderingen av komponenten och återanvända det senast renderade resultatet.
• `useCallback()`: Funktioner som definieras inuti en komponent återskapas vid varje rendering. Om du skickar dessa funktioner som props till en barnkomponent som är omsluten av `React.memo`, kommer barnet att renderas om eftersom funktions-propen tekniskt sett är en ny funktion varje gång. `useCallback` memoiserar själva funktionen, vilket säkerställer att den bara återskapas om dess beroenden ändras.
• `useMemo()`: Liknar `useCallback`, men för värden. Den memoiserar resultatet av en kostsam beräkning. Beräkningen körs bara om igen om ett av dess beroenden har ändrats. Detta är användbart för att förhindra dyra beräkningar vid varje rendering och för att bibehålla stabila objekt/array-referenser som skickas som props.

3. Smart komponentkomposition

Sättet du strukturerar dina komponenter på kan ha en betydande inverkan på prestandan. Om en del av din komponents state uppdateras ofta, försök att isolera den från de delar som inte gör det.

Istället för att ha en enda stor komponent där ett ofta ändrat inmatningsfält får hela komponenten att renderas om, lyft upp det state:t till sin egen mindre komponent. På så sätt är det bara den lilla komponenten som renderas om när användaren skriver.

4. Virtualisera långa listor

Om du behöver rendera listor med hundratals eller tusentals objekt, även med korrekta nycklar, kan det vara långsamt och minneskrävande att rendera alla på en gång. Lösningen är virtualisering eller windowing. Denna teknik innebär att man endast renderar den lilla delmängd av objekt som för närvarande är synliga i visningsområdet. När användaren scrollar avmonteras gamla objekt och nya monteras. Bibliotek som `react-window` och `react-virtualized` erbjuder kraftfulla och lättanvända komponenter för att implementera detta mönster.

Slutsats

Reacts prestanda är ingen tillfällighet; det är resultatet av en medveten och sofistikerad arkitektur centrerad kring den virtuella DOM:en och en effektiv Reconciliation-algoritm. Genom att abstrahera bort direkt DOM-manipulering kan React batcha och optimera uppdateringar på ett sätt som skulle vara otroligt komplext att hantera manuellt.

Som utvecklare är vi en avgörande del av denna process. Genom att förstå heuristiken i diffing-algoritmen — att korrekt använda nycklar, att memoisera komponenter och värden, och att strukturera våra applikationer eftertänksamt — kan vi arbeta med Reacts reconciler, inte mot den. Utvecklingen till Fiber-arkitekturen har ytterligare flyttat fram gränserna för vad som är möjligt och möjliggjort en ny generation av flytande och responsiva gränssnitt.

Nästa gång du ser ditt gränssnitt uppdateras omedelbart efter en state-ändring, ta en stund att uppskatta den eleganta dansen mellan den virtuella DOM:en, diffing-algoritmen och commit-fasen som sker under huven. Denna förståelse är din nyckel till att bygga snabbare, effektivare och mer robusta React-applikationer för en global publik.